The present invention relates to a distributed virtual environment.
Computer and video gaming has been a popular pastime ever since the first personal computers and home video game consoles arrived back in the late 1970s. In the last two or three years the nature of these games has changed dramatically due to development in two technical areas.
Firstly increasing computer power has allowed complex 3-D virtual environments to be modelled and displayed. These environments allow players both to move through a virtual world and to interact with the entities within it.
Secondly the widespread growth in computer network usage and availability (e.g. corporate LANs and the internet) has led to many games boasting multi-player capabilities.
Taken together these two developments have resulted in the basis for many games becoming a shared Virtual Environment (VE) which allow groups of people to either compete (e.g. shoot at each other or hunt for treasure etc.) or co-operate (e.g. explore or solve puzzles, business problems etc.).
In delivering shared VEs a number of key issues as follow have to be addressed.
The usual present day implementation of a shared VE places a local copy of the common environment at each client. Players interact with the local copy and broadcast these interactions to other clients or servers. For example, a switch which opens a door may be modelled as an object at each client. It has state (the switch position) and behaviour (it animates when toggled and instructs another object, a door, to open). Both the state and behaviour are held on each client. When a user activates the switch the switch not only runs the relevant behaviour locally but messages to all instances of the switch on other clients instructing them to run the same behaviour. Since changes to the environment take time to propagate across the network it is possible that two players may perform conflicting actions (e.g. both pick up the same object). Resolving this type of problem to ensure the environment seen by each player is essentially the same is known as maintaining ‘consistency’.
The time taken for information to propagate between clients is known as ‘latency’and is a key factor when trying to maintain a believable and consistent environment. High or variable latency can make it difficult to maintain a common shared view amongst all clients.
If the state of a VE persists when no players are present and players can leave and rejoin without resetting its state then it is said to be a ‘persistent’ environment. Persistent environments normally require a server (or servers) to store the state of the VE.
An ideally ‘scaleable’ VE is one in which the number of players within it can increase with no theoretical limit (i.e. no component of the system is a potential performance bottleneck).
The above issues of consistency, latency, persistence and scalableness apply generally to both gaming and non-gaming VEs. A number of additional issues as follow, namely balance, reuse, integrity and extensibility, are of particular importance to gaming environments.
Non-shared and non-persistent VEs can be carefully controlled to deliver a balanced game for the player (e.g. as a player's skill improves the challenges they face may increase in difficulty). By contrast a persistent environment may evolve over months with hundreds of players influencing its development. It is therefore very difficult for the designer to control what and whom the player encounters during his or her game session. It may be necessary to dynamically introduce objects with new behaviour or modify an object's existing behaviour to maintain a ‘balanced’ game that all users can enjoy.
Many games share common characteristics and objects (e.g. missiles that may be fired by a player, switches that operate doors and pressure pads that trigger certain behaviour in particular objects etc.). Additionally many successful games have sequels produced based on the original story line and technology. Hence the ability to ‘reuse’ or carry common components between particular implementations is highly valuable.
For persistent gaming environments to succeed players have to trust the system to ensure fair play such that the system may be said to have ‘integrity’. Few players would wish to play a game if others could cheat without fear of detection.
To create a persistent environment to which a player will wish to keep returning it is important that the environment can be extended and enhanced. Having built a community of users, ‘extensibility’ offers a means to retain them.
Existing distributed VE based games have tended to bring with them the development legacy of single player games with networking included as an additional feature rather than as an integral part. Hence a typical game will work as discussed by providing both the graphics and game-play related behaviour at each client and then synchronising with other clients by broadcasting the player's input to all other clients. This approach lacks both scaleability (as the network load at each client grows with every additional client) and persistence (as the environment state is lost when the last client leaves).
More sophisticated implementations add a specialised (i.e. unique to that game title) single central server to provide the environment state and broadcast or arbitrate on changes to the environments. This can provide a persistent environment but the single centralised server precludes scaleability. This is due to the fact that as client numbers increase both the server network traffic load and processing load increase forcing even the most powerful server to become a bottleneck.
Both of these approaches tend to place not only the game engine at the client but also the graphics engine. Whilst this has the potential to provide an efficient implementation (each client is effectively custom built for each game title) it limits balancing of the game play over time to the fixed constraints of the release version of the game rules. Also by associating the game rules so closely with the client implementation it limits reuse of components.
Somewhat more sophisticated examples of VE architecture have become apparent from a number of academic and military approaches.
The main focus of research in the VE field for academic or military systems has been the ability to deliver scaleability through suitable network architectures.
Known approaches have included techniques as follow.
Multicast network addresses may be associated with defined areas within the virtual environment. Changes within that area are broadcast via this address and clients interested in that area listen to the address to receive updates. Network traffic to a particular client therefore grows relative to the number of entities in its avatar's local area rather than in the complete environment. Such an approach is described in a paper in Presence Vol 3 No. 4 1994 by Michael R Macadonia entitled “A Network Software Architecture for large Scale Virtual Environments ”.
Alternatively, multicast network addresses may be associated with individual entities within the environment, which the entities then use to transmit their state (position or orientation etc.). As users come within range of entities (range being defined as awareness either visual or aural) they begin listening to the relevant network address and hence receive the current entity state. Such an approach may be seen in a paper entitled “MASSIVE: a Virtual Reality system for Teleconferencing” by Christ Greenhalgh and Steve Benford, published in ACM Transaction on Computer Human Interfaces, 1995.
Both of these approaches can be enhanced with simple environment state servers to offer a degree of consistency and persistence. However, these known approaches fail to address the issues directly relevant to gaming namely balance, reuse and integrity.